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DoD  Agile  Adoption: 

Necessary  Considerations, 
Concerns,  and  Changes 


Our  review  of  the  DoD  5000  series  showed  that  there  are 
no  interpretations  that  directly  preclude  or  limit  the  use  of  Agile 
methods  within  the  DoD.  There  are  some  constraints,  challeng¬ 
es,  and  even  some  supportive  instances  within  the  policy  and  in¬ 
struction.  Agile  methods,  “Can  provide  both  tactical  and  strategic 
benefits.  The  tactical  benefits  of  lower  cost  within  schedule  and 
increasing  quality  are  important;  however,  the  strategic  benefits 
of  being  responsive  and  being  able  to  adjust  to  the  current  situ¬ 
ation  more  rapidly  might  be  of  even  greater  value  [2].  This  could 
be  a  huge  factor  in  today’s  world,  where  the  DoD  needs  to  get 
results  faster  and  be  better  aligned  with  changing  needs”  [3]. 

Policies,  regulations  and  other  governing  documents  aside, 
there  are  underlying  concerns  that  will  form  the  basis  for  adopt¬ 
ing  Agile  within  the  DoD.  The  main  difference  between  using 
Agile  and  a  more  traditional  method  is  the  requirement  for 
different  management  and  technical  approaches  if  the  advan¬ 
tages  of  Agile  are  to  be  fully  realized.  In  addition,  the  Program 
Management  Office  (PMO)  needs  to  determine  how  proficient  it 
will  be  at  organizational  change  [4]. 
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Abstract.  Today’s  DoD  acquisition  environment  relies  on  the  DoD  5000 
series  of  guidelines.  Nothing  in  the  DoD  5000  series  precludes  the 
use  of  Agile  methods.  In  fact,  Agile  methods  provide  both  tactical  and 
strategic  benefits.  However,  achieving  these  benefits  is  not  likely  to  occur 
without  changes  to  the  traditional  DoD  mindset. 

Introduction 

This  article  summarizes  the  SEI  Acquisition  Support  Pro¬ 
gram’s  exploration  of  using  Agile  approaches  in  software-in¬ 
tensive  systems  developed  or  being  developed  in  the  DoD.  Our 
work  to  date  has  been  to  provide  prudent,  pragmatic  advocacy 
of  Agile  methods  for  those  within  DoD  who  want  or  have  to 
implement  those  methods.  We  have  identified  issues  and  chal¬ 
lenges  to  overcome  when  implementing  Agile  in  a  DoD  environ¬ 
ment.  These  issues  and  challenges  are  summarized  herein. 

For  purposes  of  this  article,  Agile  is  defined  as:  Agile:  An  iter¬ 
ative  and  incremental  (evolutionary)  approach  to  software  devel¬ 
opment  which  is  performed  in  a  highly  collaborative  manner  by 
self-organizing  teams  within  an  effective  governance  framework 
with  “just  enough”  ceremony  that  produces  high-quality  software 
in  a  cost  effective  and  timely  manner  which  meets  the  changing 
needs  of  its  stakeholders.1 

Further,  the  terms  “Agile  methods”  or  “Agile  approaches”  are 
commonly  used  throughout  to  characterize  a  set  of  disciplined 
incremental  methods  that  involve  strong,  continuous  end-user 
collaboration,  frequent  (two  to  four  week)  work  in  progress  de¬ 
liveries,  and  techniques  such  as  continuous  integration  and  test- 
driven  development.  Although  all  Agile  methods  are  incremental, 
not  all  incremental  methods  reflect  Agile  properties. 

Since  the  SEI  work  began,  there  has  been  considerable 
movement  within  the  government  and  DoD  to  identify  and 
implement  a  new  acquisition  process  that  can  take  advantage 
of  Agile  methods.  Attachment  2  of  the  “804  report”  [1  ]  provides 
Interim  Acquisition  Guidance  for  Defense  Business  Systems. 


Potential  Barriers  and/or  Differences  From 
Traditional  Methods 

Interviews  with  several  DoD  programs  that  are  using  or  have 
used  Agile  methods  combined  with  a  review  of  relevant  litera¬ 
ture  revealed  some  of  the  areas  where  barriers  and/or  differ¬ 
ences  from  traditional  methods  are  encountered  [3]: 

•  Acquisition  lifecycle:  Some  lifecycle  phases  lend  them¬ 
selves  to  the  use  of  Agile  better  than  others.  Remember  to 
consider  Agile  processes  and  so  that  contractually  binding 
documents,  such  as  the  request  for  proposals,  and  statement 
of  work,  support  those  processes  and  practices.  One  particular 
stumbling  block  for  the  adoption  of  Agile  tends  to  be  capstone 
technical  review  events  such  as  preliminary  design  review  and 
critical  design  review.  Agile  methods  typically  do  not  produce 
the  types  of  documentation  expected  at  these  milestones. 
Instead,  they  provide  working  prototypes  and,  in  some  cases, 

a  subset  of  requirements  implemented  as  usable  software. 
Therefore,  expectations  and  criteria  for  acceptance  need  to 
be  established  at  the  beginning  of  the  contract  that  meet  both 
the  contractual  needs  and  allow  for  the  use  of  Agile  methods. 
Since  Agile  produces  the  final  product  iteratively,  the  expecta¬ 
tions  and  criteria  for  acceptance  need  to  be  compatible. 

•  Team  environment:  A  central  concept  to  Agile  is  the 
small,  dynamic,  high-performing  cross-functional  team  (or 
teams  depending  on  the  size  of  the  program).  Testing  is  done 
concurrently  within  the  team  with  continuous  integration  [5]. 
The  teams  expect  input  from  the  end  users  throughout  this 
process.  Each  team  usually  conducts  regular  reflection  and 
adaption  called  retrospectives.  The  government  team  needs  to 
understand  and  support  this  way  of  doing  business.  Otherwise, 
using  Agile  will  have  less  than  optimal  results. 

•  End-user  access  and  involvement:  One  of  the  key  tenets 
stated  in  the  Agile  Manifesto,  the  document  that,  since  2000, 
has  guided  adopters  of  Agile  approaches,  is  “Customer 
Collaboration  over  Contract  Negotiation.’’2  This  is  usually 
accomplished  by  having  continuous  contact  with  the  end 
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user.  In  many  instances,  the  end  user  is  an  integral  member 
of  the  iteration  team.  This  is  not  always  practical  in  the  DoD 
environment,  especially  with  joint  programs  and  the  myriad  of 
stakeholders  DoD  software-reliant  systems  serve.  In  addition, 
the  real  end  user  is  an  operational  person  who  may  not  have 
any  experience  in  the  acquisition  career  field  while  the  acquirer 
may  or  may  not  have  operational  experience.  The  contractor 
and  government  usually  solve  this  problem  by  agreeing  on  a 
proxy  for  the  end  users’  day-to-day  interaction  and  inviting  end 
users  to  all  demos.  This  end  user  interaction  is  important  in 
successful  projects  using  Agile  [6]. 

*  Training  and  coaching  to  provide  knowledge  of  Agile:  Many 
of  the  Agile  concepts  are  not  new,  but  the  subtleties  and  nu¬ 
ances  of  each  Agile  method  can  be  new  to  the  uninformed.  To 
overcome  this,  all  PMO  staff  should  be  trained  in  the  contrac¬ 
tor’s  method  of  choice  [3].  It  is  important  to  set  aside  funding 
for  initial  and  ongoing  training  and  support.  Without  the  requisite 
training,  misunderstandings  will  certainly  occur  and  could  have 
disastrous  consequences.  A  coach  and/or  an  Agile  advocate 
who  has  “clout”  within  the  PMO  is  a  good  addition  to  the  PMO 
staff.  Their  presence  can  answer  daily  questions,  help  resolve 
issues  before  they  become  problems  and  help  to  ensure  the 
program  runs  smoothly  from  an  Agile  perspective.  The  Agile 
advocate/  coach  must  have  authority;  otherwise  they  will  get 
lost  in  the  chorus  of  voices  demanding  to  be  heard. 

*  Oversight  including  milestone  reviews,  documentation, 
and  evaluation  (metrics):  Traditionally,  the  government  uses 
milestone  reviews,  documentation,  and  evaluation  metrics  to 
monitor  and  evaluate  contractor  progress  on  and/or  review 
specific  aspects  of  the  proposed  technical  software  solution  [7]. 
Typically,  the  expectations  and  criteria  for  milestone  reviews  and 
documentation  are  negotiated  at  contract  award  and  certainly 
well  before  the  milestone  event  occurs  [8].  This  practice  is  not 
different  for  programs  using  Agile  methods.  However,  documen¬ 
tation  for  an  Agile  program  is  just  enough  to  meet  the  minimal 
set  of  technical  and  programmatic  needs  and  provide  continuity 
for  the  team.  This  type  of  documentation  is  not  usually  enough 
for  capstone  events.  Thus,  the  negotiations  need  to  determine 
what  is  acceptable  for  the  program  and  yet  will  work  within  the 
Agile  environment.  Tailoring  typically  takes  on  additional  impor¬ 
tance.  Some  keys  that  are  useful  in  assuring  that  the  ultimate 
outcome  is  achieved: 

*  Confirm  all  parties  have  a  stake  in  the  outcome  or  as  the  De¬ 
fense  Science  Board  has  stated  have  some  “skin  in  the  game”  [9]. 

*  Determine  how  regulatory  documentation  that  does  not  nec¬ 
essarily  contribute  directly  to  development  activities  will  be  created. 

*  Agree  to  the  intent  and  content  of  each  artifact 

*  Make  sure  all  requirements  levied  by  guiding  instructions, 
directives,  etc  are  expressly  met. 

One  analogy  for  oversight  within  the  Agile  community  could 
be  what  the  military  calls  “Commander’s  intent.”  Commander’s 
intent  provides  a  clear,  concise,  and  focused  statement  of  intent. 
Thus,  the  mission  can  continue,  even  if  the  operation  does  not 


go  as  planned  [10].  For  Agile,  the  overall  plan  is  the  intent.  If  the 
plan  does  not  work  as  expected,  the  development  team  alters 
the  plan  with  the  intent  in  mind.  This  requires  trust,  collabora¬ 
tion  and  relationship  building,  which  are  core  ideas  for  Agile. 
Performing  Agile  implementations  requires  that  the  oversight 
method,  documentation,  and  form  of  metrics  be  thoroughly 
negotiated  and  agreed  upon  in  advance  of  starting  the  program. 
When  doing  this  negotiation,  keep  in  mind  that  less  formal  does 
not  mean  undisciplined.  Agile  programs  tend  to  be  less  formal, 
but  highly  disciplined. 

•  Rewards  and  incentives:  Rewards  and  incentives  for  Agile 
teams  focus  on  the  team.  This  seems  to  be  contrary  to  the  tradi¬ 
tional  individual  based  reward  system  in  place  on  most  programs 
where  the  “hero”  gets  the  award.  Unless  the  government  is  do¬ 
ing  internal  development,  the  majority  of  change  in  this  reward 
model  is  left  to  the  contractor.  However,  the  government  can 
assist  by  considering  incentives  that  embrace  and  foster  change 
and  sharing  of  data.  “Personnel  need  to  be  incented  to  do 
significant  adoption  of  planning  and  strategy  for  the  technology 
shift  and  related  business,  legal,  and  operational  aspects”  [3]. 

•  Team  composition:  The  team  composition  for  Agile  develop¬ 
ers  is  different  than  on  traditional  teams.  Thus,  the  government 
should  consider  that  their  team  will  also  have  a  different  compo¬ 
sition.  Two  important  positions  that  are  new  to  most  government 
teams  are  those  of  Agile  advocate  and  end-user  representative. 
An  Agile  advocate,  as  described  in  Training  and  coaching  above, 
provides  real-time  answers  to  immediate  Agile  issues  for  the 
government  team.  The  end-user  representative  not  only  needs 
to  represent  the  end  users,  but  must  have  the  authority  (within 
delegated  limits)  to  direct  the  contractor.  Without  skills  in  mod¬ 
ern  software  development  approaches,  the  government  program 
office  may  have  issues  with  oversight,  which  are  quickly  visible 
in  the  fast  paced  Agile  world. 

•  Culture:  Culture  is  the  customary  knowledge,  beliefs,  be¬ 
havior,  and  traits  displayed  by  an  acquisition  organization  or  con¬ 
tractor  [3].  A  brief  comparison  of  some  typical  cultural  elements 
is  shown  in  Table  1 .  The  same  elements  can  have  significantly 
different  instantiations  depending  on  the  method  employed  [8]. 

“Traditional  project  managers  focus  on  following  the  plan 
with  minimal  change  but  the  Agile  manager  focuses  on  adapt¬ 
ing  successfully  to  inevitable  change’’  [4]. 

This  illustrates  two  very  different  mindsets.  If  the  government 
is  serious  about  adapting  Agile  methods,  then  they  will  have  to 
modify  their  mindset  so  that  they  view  software  lifecycles  from 
other  perspectives  than  the  traditional  metaphor  [11].  This  will  not 
be  easy  and  does  not  mean  traditional  methods  should  be  totally 
abandoned.  The  culture  change  needs  to  provide  flexibility  so  that 
traditional  and  Agile  methods  can  be  employed  when  and  where 
needed.  Neither  method  provides  a  solution  to  all  problems. 

For  example,  one  possible  action  that  could  be  taken  to 
bring  change  to  the  rewards  system  is  to  make  some  or  all  re¬ 
wards  team  based.  Rewards  can  be  other  than  monetary,  such 
as  choice  of  assignment,  mentoring,  training,  etc.  Downplaying 
merit  increases  and  associating  career  accomplishments  and 
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Element 

Agile  DoD 

Traditional  DoD 

Organizational  Structure 

•  Flexible  and  adaptive  structures; 

•  Self  organizing  teams, 

•  Co  located  teams  or  strong 
communication  mechanisms 
when  teams  are  distributed 

•  Command  and  control  structures 
that  are  difficult  to  change 

•  Hierarchical,  command  and  control- 
based  teams 

Rewards  System 

•  Team  is  focus  of  rewards 

•  Sometimes  team  itself 
recognizes  individuals 

•  Individual  is  focus  of  the  reward 
system 

Communications  &  Decision 

Making 

•  Daily  stand  up  meetings, 

•  Frequent  retrospectives, 

•  Information  radiators5  to 
communicate  critical  project 
information; 

•  Evocative  documents  to  feed 
conversation; 

•  “Just  enough”  documentation. 

•  Control  and  discipline  comes 
from  the  Agile  team  itself. 

•  Top  down  communication;  External 
regulations,  policies  and  procedures 
tend  to  drive  the  work.  Activities 
and  processes  documented; 

•  Traditional,  representational 
documents  used  by  the  PMO 
throughout  the  development  life 
cycle  to  oversee  the  progress  and 
discipline  of  the  developer  through 
formal  and  informal  reviews. 

Staffing  Model 

•  Cross  funcfional  teams  including 
all  roles  across  the  life  cycle 
throughout  the  lifespan  of  the 
project; 

•  Agile  advocate  or  coach 

•  End-user  representative 

•  Uses  traditional  waterfall  model 
with  separate  teams,  particularly  for 
development  and  testing 

•  Different  roles  (e.g.  developer, 
tester)  are  active  at  different 
defined  points  in  the  life  cycle  and 
are  not  substantively  involved 
except  at  those  times 

Table  1.  Comparison  of  Some  Agile  and  Traditional  DoD  Cultural  Elements 


milestones  with  promotions  is  one  strategy.  Another  strategy 
is  to  let  the  team  naturally  recognize  its  heroes  and  include  an 
appreciation  step  during  your  retrospective  [8]. 

A  final  word  about  culture.  There  is  a  big  difference  between 
doing  Agile  and  being  Agile.  Picking  an  Agile  process  and 
following  it  step  by  step  without  fully  embracing  the  culture 
can  provide  some  benefit.  However,  if  being  Agile  is  the  goal, 
then  a  culture  of  agility  needs  to  be  created  [1  2].  The  culture 
goes  beyond  using  an  Agile  software  delivery  process,  it  seeks 
to  change  what  the  team  values,  measures,  and  delivers  (i.e., 
placing  value  on  collaboration  and  personal  interactions,  work¬ 
ing  software  and  adjustment  to  change)  [8]. 

•  Integration  and  test:  Continuous  integration  and  test  of  some 
form  is  done  within  Agile  teams.  This  is  contrary  to  the  traditional 
approach  where  integration  is  done  at  the  end  of  a  release  cycle. 
If  final  integration  and  test  is  being  used  for  system  acceptance, 
then  most  likely  an  independent  external  team  will  conduct  the 
work.  However,  the  continuous  integration  and  test  during  the  de¬ 
velopment  using  Agile  methods  should  mean  that  there  are  less 
risks  to  be  overcome  as  more  issues  will  have  been  found  earlier 


in  the  lifecycle.  Additionally,  there  should  be  less  risk  of  user 
rejection  since  testing  by  the  Agile  teams  puts  validation  before 
verification  through  the  involvement  of  the  user. 

•  Managing  Agile  programs:  The  Agile  approach  to  project 
execution  places  demands  upon  all  personnel  that  are  still  tra¬ 
ditional  but  it  also  differs  from  other  execution  environments. 
The  managerial  role  is  uniquely  affected  by  the  features  of  the 
Agile  approach.  Both  the  acquiring-side  and  execution-side3 
managers  become  leaders,  coaches,  expeditors,  and  cham¬ 
pions.4  As  a  leader,  the  executing  manager  needs  to  spend 
more  time  with  the  team  to  help  create  a  “trust  factor”  so  that 
delegating  important  tasks  can  easily  be  accomplished.  The 
acquiring  manager  needs  to  determine  who  to  designate  as 
the  on-site  representative  to  maintain  adequate  visibility  into 
the  fast  emerging  product 

As  a  coach,  both  managers  need  to  assist  their  personnel 
in  making  the  transition  to  the  fast  tempo,  high  interaction 
environment  that  typifies  Agile  projects.  This  is  often  ac¬ 
complished  by  including  someone  who  has  the  role  of  Agile 
coach  for  the  project.  As  an  expeditor,  the  executing  manager 
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needs  to  identify  and  quickly  remove  any  organizational  and 
operational  impediments.  The  acquiring  manager  needs  to  se¬ 
cure  appropriate  status  information  without  unduly  interfering 
with  the  tempo  of  Agile  development  using  negotiation  and 
establishing  trust  with  the  executing  manager.  As  a  champion, 
the  executing  manager  will  need  to  translate  the  unfamiliar,  if 
not  foreign,  Agile  model  for  the  upper-level  management  and 
other  managerial  stakeholders.  In  addition  to  this,  the  acquisi¬ 
tion  manager  will  have  to  maintain  buy-in  by  external  funders 
and  stakeholders.  This  will  include  providing  a  portrayal  of 
project  status  and  accomplishments  that  is  accurate  as  well 
as  bridging  the  cultural  gap  that  exists. 

Road  to  Agile  Adoption 

During  our  interviews,  the  two  main  reasons  within  the  DoD  for 
moving  to  Agile  are  a  burning  platform  (i.e.,  if  the  program  does  not 
change  its  current  development  practice  to  improve  outcomes,  it  is 
likely  to  get  cancelled);  and  urgency  of  delivery,  i.e.,  an  operational 
need  that  cannot  wait  for  traditional  delivery  times  is  mission-critical 
enough  to  warrant  a  different  acquisition  approach  [8]. 

We  also  found  a  third,  perhaps  more  compelling  reason  to 
move  to  Agile  methods.  Section  804  of  the  National  Defense 
Authorization  Act  for  Fiscal  Year  2010  specifies  that  informa¬ 
tion  technology  systems,  “be  designed  to  include  (A)  early  and 
continual  involvement  of  the  user;  (B)  multiple  rapidly  executed 
increments  or  releases  of  capability;  (C)  early,  successive  pro¬ 
totyping  to  support  an  evolutionary  approach;  and  D)  a  modular 
open-systems  approach”  [1].  The  fact  that  Agile  methods  are 
more  compatible  “out  of  the  box”  with  all  four  of  these  directives 
than  typical  IT  acquisition  practices  is  an  encouraging  sign  that 
appropriate  use  of  these  methods  in  the  future  will  be  supported. 

For  those  who  have  been  using  Agile  methods  for  some  time, 
some  common  themes  that  characterized  continuing  motivation 
for  change  included: 

•  A  sense  of  true  accomplishment  when  they  delivered  a  release 
that  they  knew  incorporated  functionality  the  end  user  needed. 

•  A  short  time  span  for  seeing  the  differences  their  work 
made  to  their  end  users. 

•  Encouraging  (often  laudatory)  user  feedback  that  clearly 
communicated  the  value  of  their  approach. 

•  Consistent  ability  to  meet  or  exceed  user  expectations. 

•  Previous  inability  to  deliver  value  within  agreed  timespans 
and  costs. 

In  order  to  adopt  Agile  methods,  best  practices  in  adoption 
and  organizational  change  management  need  to  be  considered. 
Some  of  these  topics  are: 

•  Understanding  your  adopter  population:  [13]  By  this  we 
mean  understand  the  characteristics  of  the  people  both  as  indi¬ 
viduals  and  as  a  group.  For  those  in  the  DoD  who  have  adopted 
Agile  methods,  they  have  been  pathfinders  in  terms  of  finding 
ways  to  “work  Agile”  in  an  environment  that  demands  artifacts 
and  evidence  based  on  “working  traditional.”  Successful  adop¬ 
tion  across  a  wide  spectrum  of  appropriate  DoD  programs  will 
not  occur  until  more  communication  and  implementation  support 
mechanisms  are  available  [14]. 


•  Understanding  the  cycle  of  change:  Change  takes  effort  and 
time  [1 5].  From  our  interviews,  it  was  common  to  phase  adoption 
of  Agile  methods  over  a  period  of  time  to  allow  the  staff  to  get 
accustomed  to  a  new  set  of  practices. 

•  Understanding  your  adoption  risks:  Know  where  you  are  in 
terms  of  practices,  skills,  sponsorship,  and  values.  The  adoption 
approach  used  by  the  majority  of  programs  interviewed  heavily 
leveraged  external  training  and  coaching  [16]. 

•  Building  transition  mechanisms  to  mitigate  adoption  risks: 
Some  potential  mechanisms  are  articles  in  CrossTalk,  Defense 
Acquisition  News,  etc.  on  programs  successfully  using  Agile 
methods  and  conference  tracks  and  workshops  that  highlight  the 
benefits  and  risks  associated  with  adopting  Agile  practices  [17]. 

Conclusion 

Agile  methods  can  provide  the  benefits  of  being  responsive 
and  being  able  to  adjust  to  the  current  situation  faster  than  when 
using  traditional  methods.  Adopting  Agile  methods  is  not  without 
work  to  overcome  barriers.  Others  have  done  so  and  there  is  a 
wealth  of  information  starting  to  accumulate  to  assist  organiza¬ 
tions  wanting  to  make  this  change.  The  authors  of  the  two  papers 
summarized  here  are  continuing  to  research  this  arena  and  add  to 
the  body  of  knowledge  available  for  DoD  use.^ 
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1.  <http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm> 

2.  See  <http://Agilemanifesto.org/history.html> 

3.  The  executing-side  manager  could  be  a  development  contractor  or  part  of  an  organic 
government  team,  such  as  an  Air  Logistics  Center  team 

4.  The  common  traits  takes  inspiration  from  Dean  Leffingwell  [5]  then  alters  and  expands 
them  to  address  inserting  Agile  practices  into  DoD  acquisition. 

5.  Information  radiator  -  is  a  large,  highly  visible  display  used  by  software  development 
teams  to  track  progress.  The  term  was  first  coined  by  Alistar  Cockburn.  See 
<http://www.atlassian.com/wallboards/information-radiators.jsp> 
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